comp2013group7fandomcom-20200214-history
User blog:Michboon/Automation and Rules
(Part 2 of my COMP2014 catch-up posts) The first new feature I decided to add to the system was the ability to add rules and react to events in the house. Up until now, our system has only been able to control the house which seems lacking for a home automation system. We needed a way for users to specify rules such as “When the lounge door opens, if it is dark outside then close the curtains in the room and turn the lights on”. We went with a system of “Events”, “Conditions” and “Actions”. The first thing to think about was the scope of the rules. For example, I wanted the user to be able to specify events that were triggered not just on single items within the house but groups such as “Any window in the kitchen” or “Any door downstairs”. To implement this I needed to let events specify an item id, room id and item type so that I could then figure out which scope the rule was using. If an item id was given then it clearly refers to a specific item, if a room id and type is given then it is for all items of that type in the room and if neither is given but a type is then it is for any item of that type in the house. Next, the conditions were much more straightforward. Since the conditions would always just depend on some sort of state or collection of states within the house we just needed to check the relevant states to continue to processing the list of actions. For now, all conditions are “AND” with each other and if the user wishes to “OR” them they must create a new rule to go alongside it. This is to try and keep the interface cleaner since rules are unlikely to need that level of complexity. Once the conditions are passed the actions are executed. The final consideration was for multiple events being triggered by a single change of state and the problems that could be caused by conflicting events. For example, there would be an issue if 2 events were triggered and one wanted to turn the lights on but the other wanted to turn the lights off. I made the Python check for all the eligible events and then look through and ignore any that had conflicting actions. Currently, this ignores whether or not a condition passes which is a slight flaw. It would be bad if Event B was discarded because it conflicted with Event A but then Event A did not pass the conditions anyway. I am considering coming back to this at a later stage in the project but for now I decided that it was too much since it would involve much more repeated checks on the hardware which could increase the time taken since it relies on the network. Caching states could be a way around this. Category:Blog posts